Computer database programs allow a user to store data in one or more tables of a database. Some conventional computer database programs group one or more tables or portions of tables into a single named unit, such as a tablespace in the conventional Oracle8 product available from Oracle Corporation of Redwood Shores, Calif. As used herein, a "tablespace" is any group of one or more tables or portions of tables in a database.
Computer database programs store information in one or more files. In addition to storing the data used by the users of the database, conventional database programs maintain information about the data in the database in order to allow the database to operate. Information about the data may include definition information about the type and arrangement of the data stored in the data files, and information about the locations and names of the files that store the information used by, or stored in, the database. Some conventional databases, such as the Oracle8 product available from Oracle Corporation of Redwood Shores, Calif., store data in a database in one or more data files, store information about the type and arrangement of the data in the database in a data dictionary file, and store information about the files related to a database in a control file.
Because computer files such as database files may become damaged or corrupted, an operator may make backup copies of the database files. Backup copies made at many points in time may be retained to allow the file to be restored as of any of those points in time.
If any one of the database files is damaged or corrupted, some conventional database programs require an operator to use the backup files to restore all of the files associated with a database. Because large databases may contain many files of data, this approach can be burdensome to the person who must restore the various files and can seem especially burdensome if only one of the many files to be restored is actually damaged or corrupted.
There is an additional reason why restoration to a particular point in time of only part of a database is desirable. If erroneous changes are made to one part of the database, but correct changes are made to another part of the database, the user must correct the erroneous changes. To do this, the user is faced with two choices to correct the database. The erroneous changes can be backed out, manually for example, and then reentered, a laborious process that itself is prone to error. Alternatively, the user can first restore the database to the point in time of the most recent backup file in which the erroneous changes did not exist in the database. However, if the database does not allow transaction logs to be used to automatically enter only the correct changes without the erroneous changes, the user must re-enter the correct changes, a potentially laborious process prone to error.
Even if the database is restored to a point in time of one of the backup files, because the backup files are made at discrete intervals, it may not be possible to restore the database to just before the precise point in time the erroneous changes were first introduced into the database. As a result, correct changes in both portions of the database from the point in time of the backup used to restore the database to the point in time the erroneous changes were made to the database will not exist in the database following the restoration, and may have to be reentered.
Because the files not damaged or corrupted may be interrelated with the damaged or corrupted file or files, it may not be possible to simply restore the file containing the damaged or corrupt information. For example, the information contained in the database tablespaces may be stored in one file and the data definition information may be stored in another file. If the definitions of the data in the data dictionary have changed since a damaged database data file was last backed up, merely restoring the damaged data file would cause the restored data file to be inconsistent with the definitions stored in the data dictionary file. If other database tablespaces are stored in other database data files, other database data files may be related to the damaged data file, and these files may have also changed after the backup of the damaged data file. Merely restoring the damaged the data file could cause the other related database data files to become inconsistent with the restored database data file.
Some conventional database programs implement built in mechanisms to allow automated recovery of a part of the database. However, to allow the recovery of a part of the database, the database program must compute and maintain additional information during regular operation of the database. This can slow the operation of the database during processing of regular, day-to-day transactions.
There is therefore a need for a system and method to allow a party to restore a part of a database to a particular point in time that may not match a point in time the database was backed up, without restoring all of the files associated with the database and without slowing the performance of the database in processing regular transactions.